<p>LPC Basics<br>
Written by Descartes of Borg<br>
23 April 1993</p>

<h3>Introduction</h3>
<p><strong>This manual, how to use it, and its terms</strong></p>
<p>I have seen a lot of requests lately on USENET for LPC manuals. In addition,
   the immortals on my mud have been telling how good the building documentation
   of Nightmare is, but that there was just no adequate explanation of the LPC
   programming language. So I decided to try my hand at writing a manual. Some
   things you should keep in mind. LPC is a very easy programming language to
   learn, and it has real value in that place most of us know as the real world.
   I began playing muds in 1991, and in the space of a month created an unimpressive
   area and musician's guild on the original Bates College MUD called Orlith.
   After that, I moved to Los Angeles for a year and had no contact with mudding
   or computers. In June of 1992, I was back on the internet and a wizard of
   Igor. In September of 1992 I began coding the Nightmare mudlib for our use,
   and then later decided to distribute it due to there not being any mudlibs
   for MudOS at the time that a person could just throw up a running mud with
   (now, that of course is not the case :)). So, I have been doing serious coding
   for less than a year. As a Philosophy major in a world of Computer Science
   majors, I just want to make clear that it is not at all required that you
   have ever done anything with your computer than log into a mud in order for
   you to really come to understand LPC coding. This manual makes the following
   assumptions: Someone has taught you basic UNIX commands like ls, cd, mkdir,
   mv, rm, etc. You know how to enter your mud's editor and write a file. No
   other assumptions are made. If you know C, you are handicapped in that LPC
   looks a lot like C, but it is not C. Your preconceptions about modular programming
   development will be a hinderence you will have to overcome. If you have never
   heard of the C programming language (like me in May of 1991), then you are
   only missing an understanding of the simple constructs of C like the flow
   of program execution and logical operators and such. So a C guru has no real
   advantage over you, since what they know from C which is applicable to LPC
   is easy to pick up. The stuff they know about C which makes them a guru is
   irrelevant to LPC.
</p>
<p>The chapters of this manual are meant to be read in order. Starting with
   the introduction, going sequentially through the chapter numbers as ordered
   in the contents file. Each chapter begins with a paragraph or two explaining
   what you should have come to understand by that point in your studies. After
   those introductory paragraphs, the chapter then begins to discuss its subject
   matter in nauseating detail. At the end of the chapter is a briefly worded
   summary of what you should understand from that chapter if I have been successful.
   Following that may or may not be some sidenotes relevant to the subject at
   hand, but not necessary to its understanding.
</p>
<p>If at any time you get to a chapter intro, and you have read the preceeding
   chapters thoroughly and you do not understand what it says you should understand
   by that point, please mail me! Clearly, I have failed at that point and I
   need to know where it is I have gone wrong so I can revise it properly. Similarly,
   if you do not understand what the chapter summary says you should, please
   mail me. If your mud is on the MudOS intermud system, mail descartes@nightmare.
   Otherwise mail <a href="mailto:borg@hebron.connected.com">borg@hebron.connected.com</a>.
</p>

<p><strong>Some basic terms this manual uses:</strong></p>
<dl>
  <dt>driver
  <dd>This is the C program which is the game. It accepts incoming sockets (links
    to other computers), interprets LPC code defined by the mudlib, keeps mud
    objects in memory, makes periodic attempts to clean unused mud objects from
    memory, makes periodic calls to objects, and so on.
  <dt>mudlib
  <dd>LPC code which defines the world in which you are in. The driver of itself
    is not a game. It is just a program which allows the creation of a multi-user
    environment. In some sense, the driver is like an LPC compiler, and the
    mudlib is like a compiler's library (a very loose analogy). The mudlib defines
    basic objects which will likely be used over and over again by people creating
    in the mud world. Examples of such objects are /std/room (or /room/room),
    /std/user.c (or /obj/player.c), and so on.
  <dt>area or castle
  <dd>Specific creator coded objects which often use a feature of LPC called
    inheritance to make use of the properties of basic mudlib objects and turn
    them into specific objects to be used by players in the game
  <dt>object
  <dd>a room, a weapon, a monster, a player, a bag, etc. More importantly, every
    individual file with a .c extension is an object. Objects are used in different
    ways. Objects like /std/living.c are inherited by objects like monster.c
    and user.c. Others are cloned, which means a duplicate of that code is loaded
    into memory. And still others are simply loaded into memory to be referenced
    by other objects.
  <dt>native and compat
  <dd>these two terms refer to two popular flavours of drivers. Native mode
    mudlibs make use of on the design of LPMud driver 3.0 and later. You may
    have a 3.0 driver however, but have a 2.4.5 style mudlib. This is what is
    meant by compat mode. Mudlibs which are native mode are any for MudOS, CD,
    and LPMud mudlibs that are listed as native. Compat mudlibs are any LPMud
    mudlib before 3.0 and those which are 3.* compat mudlibs. I believe Amylaar's
    is compat.
</dl>

<p><i>Good Luck!</i><br>
George Reese<br>
(Descartes of Borg)<br>
12 July 1993<br>
<a href="mailto:borg@hebron.connected.com">borg@hebron.connected.com</a>
</p>
